What is the operational difference between a rolling upgrade of a replicated cluster and an in-place upgrade of a single-node deployment?

The fundamental difference is that a replicated cluster has redundancy, so you can upgrade one node at a time while the others continue to serve. A rolling upgrade takes each node out of service, upgrades it, restarts it, and waits for it to rejoin and catch up before moving to the next node. At any moment, the cluster has enough healthy replicas to serve traffic, so the upgrade is transparent to users. A single-node deployment has no redundancy, so upgrading it means stopping the process, upgrading, and restarting - during which the service is unavailable. The downtime is the sum of the stop time, the upgrade time, and the restart and warm-up time. For a single-node deployment, the only way to avoid downtime is to run two nodes (which makes it a cluster) or to use a managed service that handles the upgrade. The rolling upgrade is one of the main operational benefits of running a replicated cluster, and it is why production deployments use replication even when they do not need the read scaling.

The mechanism that makes a rolling upgrade safe is that Qdrant's replication and consensus handle the temporary loss of a node. When a node is taken out, the cluster detects it, promotes a replica if the node was a primary, and continues serving. The node is upgraded and restarted, rejoins the cluster, and catches up on missed writes via WAL replay or a snapshot transfer. The cluster waits for the node to be fully caught up before moving to the next. This is why the upgrade is slower than a single-node upgrade - it is paced by the catch-up time - but it is zero-downtime. The single-node upgrade has no such coordination: the process stops, and there is no replica to serve during the upgrade. The downtime can be reduced by pre-staging the new version and minimizing the restart time, but it cannot be eliminated. The difference in operational risk is significant: a rolling upgrade can be paused or rolled back if a node fails to rejoin, while a single-node upgrade has no fallback if the new version does not start.

The trade-off is between cost and availability. A replicated cluster costs more but enables zero-downtime upgrades and better availability. A single-node deployment is cheaper but requires downtime for every upgrade. For a production system, the cost of the extra nodes is usually justified by the availability benefit. The common mistakes are: (1) upgrading a cluster without replication, which turns a rolling upgrade into a downtime event; (2) not testing the new version in staging, so a compatibility issue is discovered in production; (3) not monitoring the catch-up time, so a slow rejoin extends the upgrade window; (4) upgrading during peak traffic, when the loss of a replica's capacity matters; (5) not having a rollback plan if the new version has a problem. Version note: the rolling upgrade procedure and the cluster's behavior during a node restart have evolved across Qdrant releases. Some versions handle the rejoin more gracefully than others. Test the upgrade process on your version in staging.

Version-dependent: the rolling upgrade procedure and the cluster's behavior during a node restart have changed across Qdrant releases. In some versions, the cluster handles the rejoin more gracefully; in others, the operator must wait for a manual step. Verify the procedure on your version and test it in staging before doing it in production.